View figure.
The Internet has become a popular, low-cost backbone infrastructure. Because of its universal reach, many companies have considered constructing a secure virtual private network (VPN) over the public Internet. The challenge in designing a VPN for today's global business environment will be to exploit the public Internet backbone for both intra-company and inter-company communication, while still providing the security and reliability of the traditional private, self-administered corporate network.
This chapter defines a VPN and explains the benefits of implementing a VPN. It also discusses security considerations and planning aspects and describes VPN solutions available in the market today.
With the explosive growth of the Internet, companies are beginning to ask, What is the best way for us to exploit the Internet for our business? Initially, companies were providing corporate Web sites to promote their company's image, products and services. Today the Internet potential is limitless, and the focus has shifted to e-business--using the global reach of the Internet for easy access to key business applications and data that reside in traditional I/T systems. Companies can now securely and cost-effectively extend the reach of their applications and data across the world through the implementation of secure VPN solutions.
Figure 19-1. Virtual Private Networks
| View figure. |
A VPN is an extension of an enterprise's private intranet across a public network such as the Internet, that creates a secure private connection, essentially through a private tunnel. VPNs securely convey information across the Internet by connecting remote users, branch offices and business partners into an extended corporate network, as shown in Figure 19-1. Internet Service Providers (ISPs) offer cost-effective access to the Internet (via direct lines or local telephone numbers), enabling companies to eliminate their current, expensive leased lines, long distance calls and toll-free telephone numbers.
Within the layered communications protocol stack model, the network layer (IP in the case of the TCP/IP stack) is the lowest layer that can provide end-to-end security. Network-layer security protocols provide blanket protection for all upper-layer application data carried in the payload of an IP datagram, without requiring a user to modify the applications.
The solutions are based on the IP Security architecture (IPSec) open framework, defined by the IPSec Working Group of the IETF. IPSec is called a framework because it provides a stable, long lasting base for providing network layer security. It can accommodate today's cryptographic algorithms, and can also accommodate newer, more powerful algorithms as they become available. IPv6 implementations are required to support IPSec, and IPv4 implementations are strongly recommended. In addition to providing the base security functions for the Internet, IPSec furnishes flexible building blocks from which robust, secure VPNs can be constructed.
The IPSec Working Group has concentrated on defining protocols to address several major areas:
The following list presents the principal IPSec protocols:
The IP Authentication Header (AH) provides connectionless integrity (that is, per-packet) and data origin authentication for IP datagrams. It also offers protection against replay. Data integrity is ensured by the checksum generated by a message authentication code (for example, MD5); data origin authentication is ensured by including a secret shared key in the data to be authenticated; and replay protection is provided by use of a sequence number field within the AH header. In the IPSec vocabulary, these three distinct functions are lumped together and simply referred to by the name authentication.
AH authenticates as much of the IP datagram as possible. Some fields in the IPheader change en-route and their value cannot be predicted by the receiver. These fields are called mutable and are not protected by AH. The mutable IPv4 fields are:
AH is identified by protocol number 51, assigned by the IANA. The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header contains this value in its Protocol (IPv4) or Next Header (IPv6, Extension) field.
AH processing is applied only to non-fragmented IP packets. However an IP packet with AH applied can be fragmented by intermediate routers. In this case, the destination first reassembles the packet and then applies AH processing to it. If an IP packet that appears to be a fragment (offset field is non-zero, or the More Fragments bit is set) is input to AH processing, it is discarded. This prevents the so-called overlapping fragment attack, which misuses the fragment reassembly algorithm in order to create forged packets and force them through a firewall.
Packets that failed authentication are discarded and are never delivered to upper layers. This mode of operation greatly reduces the chances of successful denial of service attacks, which aim to block the communication of a host or gateway by flooding it with bogus packets.
AH can be used in two modes: transport mode and tunnel mode. The transport mode is used by hosts instead of gateways. Gateways are not even required to support transport mode. Transport mode requires less processing overhead, but the mutable fields are not authenticated.
When protection of the IPv4 fields is required, tunneling should be used. The payload of the IP packet is considered immutable and is always protected by AH.
The tunnel mode is used whenever either end of an SA is a gateway. Thus, between two firewalls, the tunnel mode is always used. Although gateways are required to support tunnel mode only, often they also support transport mode. This mode is allowed when the gateway acts as a host, such as in cases when traffic is destined to itself. Examples are SNMP commands or ICMP echo requests.
In tunnel mode, the outer headers' IP addresses do not need to be the same as the inner headers' addresses. For example, two security gateways may operate an AH tunnel which is used to authenticate all traffic between the networks they connect together. This is a very typical mode of operation. Hosts are not required to support tunnel mode, but often they do.
Tunnel mode offers total protection of the encapsulated IP datagram and the possibility of using private addresses. However, there is an extra processing overhead associated with this mode.
| Note: | The original AH specification in RFC 1825 does not list tunnel mode as a requirement. Because of this, there are IPSec implementations based on that RFC that do not support AH in tunnel mode. This has implications in the ability to implement certain scenarios. |
The IP Encapsulating Security Payload (ESP) provides data confidentiality (encryption), connectionless integrity (that is per-packet), data origin authentication and protection against replay. ESP always provides data confidentiality, and can also optionally provide data origin authentication, data integrity checking, and replay protection. If you compare ESP to AH, you will see that only ESP provides encryption, while either can provide authentication, integrity checking and replay protection.
When ESP is used to provide authentication functions, it uses the same algorithms used by the AH protocol. However, the coverage is different.
Either ESP or AH may be applied alone, in combination with the other or even nested within another instance of itself. With these combinations, authentication and/or encryption can be provided between a pair of communicating hosts, between a pair of communicating firewalls or between a host and a firewall.
An SA contains all the relevant information that communicating systems need in order to execute the IPSec protocols, such as AH or ESP. For example, an SA will identify the cryptographic algorithm to be used, the keying information and the identities of the participating parties. ISAKMP defines a standardized framework to support negotiation of SAs, initial generation of all cryptographic keys and subsequent refresh of these keys. Oakley is the mandatory key management protocol that is required to be used within the ISAKMP framework. ISAKMP supports automated negotiation of SAs and automated generation and refresh of cryptographic keys. The ability to perform these functions with little or no manual configuration of machines will be a critical element as a VPN grows in size.
Secure exchange of keys is the most critical factor in establishing a secure communications environment. No matter how strong your authentication and encryption are, if your key is compromised, they are worthless. Since the ISAKMP procedures deal with initializing the keys, they must be capable of running over links where no security is assumed. That is, they are used to bootstrap the IPSec protocols. Hence, the ISAKMP protocols use the most complex and processor-intensive operations in the IPSec protocol suite.
ISAKMP requires that all information exchanges are both encrypted and authenticated. No one can eavesdrop on the keying material, and the keying material will be exchanged only among authenticated parties.
This section discusses three of the most likely business scenarios that are well suited to the implementation of a VPN solution:
The following sections provide a brief overview of each of these scenarios.
The branch office scenario securely connects two trusted intranets within your organization. Your security focus is now on both protecting your company's intranet against external intruders and securing your company's data while it flows over the public Internet. This differs from the business partner/supplier network discussed next, where the focus is on enabling your business partners/suppliers access to data in your corporate intranet.
Suppose corporate headquarters wants to minimize the costs incurred from communicating with its own branches. Today, the company may use switched and/or leased lines, but it wants to explore other options for transmitting their internal confidential data that will be less expensive, more secure and globally accessible. By exploiting the Internet, branch office connection VPNs can easily be established to meet the company's needs.
Figure 19-2. Branch Office Connection Network
 View figure. |
As shown in Figure 19-2, one way to implement this VPN connection between the corporate headquarters and one of its branch offices is for the company to purchase Internet access from an ISP, such as IBM Global Services. IBM eNetwork routers or firewalls with integrated firewall functionality, or in some cases an IBM server with IPSec capability would be placed at the boundary of each of the intranets to protect the corporate traffic from Internet hackers. With this scenario, the clients and servers need not support IPSec technology, since the IPSec-enabled routers (or firewalls) would be providing the necessary data packet authentication and encryption. With this approach, any confidential information would be hidden from untrusted Internet users, with the router or firewall denying access to potential attackers.
With the establishment of branch office connection VPNs, the company's corporate headquarters will be able to communicate securely and cost-effectively with its branches, whether located locally or far away. Through VPN technology, each branch can also extend the reach of its existing intranet to incorporate the other branch intranets, building an extended, enterprise-wide corporate network.
This company can also easily expand this newly created environment to include its business partners, suppliers, and remote users through the use of open IPSec technology.
Industry-leading companies are those that can communicate inexpensively and securely to their business partners, subsidiaries, and vendors. Many companies have chosen to implement switched and/or purchase leased lines to achieve this interaction. But this is often expensive, and geographic reach may be limited. VPN technology offers an alternative for companies to build a private and cost-effective extended corporate network with worldwide coverage, exploiting the Internet or other public network.
Suppose you are a major parts supplier to a manufacturer. Since it is critical that you have the specific parts and quantities at the exact time required by the manufacturing firm, you always need to be aware of the manufacturer's inventory status and production schedules. Perhaps you are handling this interaction manually today, and have found it to be time consuming, expensive and maybe even inaccurate. You would like to find an easier, faster and more effective way of communicating. However, given the confidentiality and time-sensitive nature of this information, the manufacturer does not want to publish this data on their corporate Web page or distribute this information monthly via an external report.
To solve these problems, the parts supplier and manufacturer can implement a VPN, as shown in Figure 19-3. A VPN can be built between a client workstation, in the parts supplier's intranet or directly to the server residing in the manufacturer's intranet. The clients can authenticate themselves either to the router or firewall protecting the manufacturer's intranet, directly to the manufacturer's server (validating that they are who they say they are), or to both, depending on your security policy. Then a tunnel could be established, encrypting all data packets from the client, through the Internet, to the required server.
Figure 19-3. Business Partner/Supplier Network
 View figure. |
One way to implement this scenario is for the companies to purchase Internet access from an ISP, such as IBM Global Services. Then, given the lack of security of the Internet, either an IPSec-enabled router, an IBM eNetwork firewall or an IBM server with IPSec capability can be deployed as required to protect the intranets from intruders. If end-to-end protection is desired, then both the client and server machines need to be IPSec-enabled as well.
Through the implementation of this VPN technology, the manufacturer would easily be able to extend the reach of their existing corporate intranet to include one or more parts suppliers (essentially building an extended corporate network) while enjoying the cost-effective benefits of using the Internet as their backbone. Now, with the flexibility of open IPSec technology, the ability for this manufacturer to incorporate more external suppliers is limitless.
When implementing a VPN, a set of security configuration criteria must be established. Decisions such as which security algorithms are to be used by each IPSec-enabled box and when the keys are to be refreshed are all aspects of policy management. With respect to key technology, almost all of today's currently popular security protocols begin by using public key cryptography. Each user is assigned a unique public key. Certificates, in the form of digital signatures, validate the authenticity of your identity and your encryption key.
These certificates can be stored in a public key database, such as a secure DNS, that can be accessible via a simple protocol, such as LDAP.
A remote user, whether at home or on the road, wants to be able to communicate securely and cost-effectively back to his/her corporate intranet.
Although many still use expensive long-distance and toll-free telephone numbers, this cost can be greatly minimized by exploiting the Internet. For example, you are at home or on the road, but need a confidential file on a server within your intranet. By obtaining Internet access in the form of a dial-in connection to an ISP such as IBM Global Services, you can communicate with the server in your intranet and access the required file.
One way to implement this scenario is to use an eNetwork VPN IPSec-enabled remote client and router or firewall, as shown in Figure 19-4. The client accesses the Internet via dial-up to an ISP, and then establishes an authenticated and encrypted tunnel between itself and the router or firewall at the intranet boundary.
By applying IPSec authentication between the remote client and the router or firewall, you can protect your intranet from unwanted and possibly malicious IP packets. And by encrypting traffic that flows between the remote host and the router or firewall, you can prevent outsiders from eavesdropping on your information.
Figure 19-4. Remote Access Network
 View figure. |
The three scenarios discussed in this section are the basis for the IPSec implementation and configuration examples described in this book. The next chapter provides step-by-step procedures for configuring IPSec tunnels with IBM Routers.
Policy based networking is an architecture whereby the network devices determine if an action other than routing should be applied to received traffic. For example, should the traffic be secured by IP Security, or does the traffic have special Quality of Service (QoS) requirements? In order for network devices to make decisions based on policy, they need to be configured to do so. It is the configuration of multiple devices that is difficult to scale to a large network. Managing these multiple configurations can be made easier by developing a method of storing, retrieving, and distributing common configuration objects. The accepted method of storing, searching, and sharing configuration data is in a policy database.
In order to develop a policy, one must first define the requirements, such as traffic security and performance. An example of a traffic handling requirement is: Traffic going between a branch office across the Internet to the corporate office should be secured. This requirement is used to define what is known as the policy. For the previously mentioned requirement, the network device must be able to identify which of the packets that it receives are coming from the branch office and are destined for the corporate office. A profile is created based on attributes such as IP source and destination addresses or protocols to match against the received packets. If the attributes of the packet match the attributes of the profile, then the packet is handled in a manner prescribed by an action definition. As one might assume, actions define such things as encryption and QoS methods.
All of the policies, profiles, and actions can be stored in a database. By using a database, certain profiles and actions can be reused and combined in different ways to create multiple policies without individually creating each policy in the device configuration. Change management is facilitated by the ability to make a single change in an object that will be propagated to any policy which uses that object. For example, multiple VPN tunnels could be using a common encryption method. If it were desired to change the encryption method for all tunnels, only one change would need to be made.
Four protocols will be able to use the policy database. These protocols are ones with repetitive data--repetitive within a device and possibly across the network. The following protocols are supported:
Every policy has a traffic profile and an availability period. You can specify that policy only applies to traffic arriving and leaving by specific interfaces. It is only necessary to identify the users if you are going to specify the IKE action.
An IPSec action may specify a drop, pass, or secure action. If the action is drop then all packets matching this policy are dropped. If the action is pass with no security, then all the packets are passed in the clear text. On the other hand, if the action is pass with security then all the packets are secured by means of an SA specified by this action. The IPSec action also contains the IP addresses of the tunnel end-points for the IPSec tunnel and IKE SAs.
One option for entering policies into the database is to manually configure each device. On IBM routers, the command line interface (talk 6) or configuration program is used to add objects such as policies, profiles, validity periods, IPSec actions and other security and performance related objects. As previously mentioned, some of these objects can be reused with different policies which reduces the amount of manual configuration. This may be acceptable and even desirable in a small network, but this method does not work well in large networks.
An alternative solution to configuring each network device is to input all policies into a central server and distribute the policies to the devices. The IETF has proposed that the central server is an LDAP server and that each network device is an LDAP client. For now, it is enough to understand that the LDAP server can store and distribute policies. In Figure 19-5, the policies on the right side are distributed by the LDAP Server.
For further discussion of this topic, point your Web browser to the following address:
http://www.networking.ibm.com/support/networkutility/downloads
Figure 19-5. Policy distribution manually and by LDAP Server
 View figure. |
IKE addresses concerns with manual tunnels for IPSec. Manual tunnels require difficult manual configuration of SA characteristics and keys.
IKE, previously known as ISAKMP/Oakley Key Resolution, defines a standardized framework to support automated negotiation of an SA, initial generation of all cryptographic keys, and subsequent refreshes of these keys. The negotiated SAs and keying materials are used to protect IKE exchanges and also other security functions, such as AH and ESP. Secure exchange of keys is the most critical factor in establishing a secure communications environment. Since IKE deals with initializing keys, it must be capable of being used over links where no security can be assumed. The IKE protocols use the most complex and processor-intensive operations in the IPSec protocol suite.
IKE requires that all information exchanges are both encrypted and authenticated. It has also been designed to protect against several well-known exposures:
IKE has two phases. In phase I, the cryptographic operations are the most processor-intensive, since this phase is designed to exchange a "master secret" when there is no security in place. The master secret is used to derive the keys which will be used to protect users' traffic. Phase I is only concerned with establishing the protections suite for IKE messages themselves; it does not establish any SAs of keys for protecting user data. Phase I operations need only be done infrequently, and a single phase I negotiation can be used to support multiple phase II exchanges. Figure 19-6 shows the messages exchanged in Phase I. These 6 messages show the exchanges between two pairs in Main-mode.
Figure 19-6. Phase I Message Exchange In IKE Main Mode
 View figure. |
Message 1 is sent by the IKE peer that wishes to establish an ISAKMP tunnel. The first message is comprised of a standard IP header and UDP header. All ISAKMP messages are carried in a UDP packet with destination port 500. The UDP payload is comprised of an ISAKMP header, an SA payload and one or more proposal and transform payloads.
Message 2 contains the single proposal and transform that the responder wishes to accept.
Message 3 and message 4 exchange information from which the cryptographic keys will eventually be derived. All the information is exchanged in the clear. The messages contain a key exchange payload and the nonce payload. The key exchange payload contains the Diffie-Hellman (DH) public value. The exponent is the DH private value which is always kept secret. The nonce payload carries a large random number which is generated according to very strict mathematical guidelines. This payload is used to guarantee the connection exists and protect against replay attacks.
Both IKE devices now have each other's public DH values and their own keys. They can perform the DH calculation to generate a shared secret. The shared secret is the DH public value to the power of the private key. In Figure 19-6, the private DH values are A and B. In this case, the shared secret is a number equal in both routers which derived by using DH values A and B. The value of g is already agreed by the routers in messages 1 and 2.
From this point on, the keys can be generated with the information which is already exchanged and established. Now both the routers know:
Figure 19-7. Generating the Keys
 View figure. |
As seen in Figure 19-7, both devices now generate a master key, which is referred to as the SKEYID. This is the keying material for which the actual cryptographic keys will be derived. The method of generating the master keys depends on the authentication message agreed in message 2. The options are:
The purpose of message 5 is to allow the responder to authenticate the initiator and message 6 allows the initiator to authenticate the responder. The format of the messages depends on whether the IKE peers have agreed to do authentication via pre-shared keys or digital signatures.
At this point, the phase I messages are complete in the main-mode. Each peer has authenticated itself to its peer, both have agreed on the characteristics of the ISAKMP SA and have derived the same set of keying material.
The other approach in phase I is the aggressive mode. Aggressive mode is less processor intensive, with only 3 message exchanges rather than six. However, aggressive mode is less secure.
The message 1 in aggressive mode is similar to message 1 of main mode in that it offers the peer a choice of ISAKMP SAs. It also includes the key exchange payload, the nonce payload and identity payloads. These would have been sent in messages 3 and 5 in main mode. This means that for aggressive mode, the identity of the initiator is sent in the clear, unlike in main mode when it is encrypted.
Message 2 in aggressive mode is the responder indicating which of the ISAKMP SAs he wishes to accept. In the response, he also includes the payloads that would have been present in message 2, message 4 and message 6 of main mode.
This means that the identity of the responder, his certificate and signature is sent in the clear, if authentication is via digital signatures. If authentication is via pre-shared keys, the identity and hash payloads are carried in the clear. Remember than in message 6 of main mode, the authentication material would have been encrypted before sending.
Message 3, which is encrypted, is sent to allow the responder to authenticate the initiator. The initiator sends the hash payload (pre-shared keys) or certificate and signature payload (digital signature mode) to the responder. The contents of the payloads is described in the discussion of main mode. The responder would then use the provided information to authenticate the initiator as described for message 5 in main mode.
Phase II exchanges negotiate the SAs and keys that will be used to protect user data exchanges. Phase II IKE messages are protected by the IKE SA generated in phase I. Phase II negotiations generally occur more frequently than phase I, typically once every few minutes, whereas phase I can be as far apart as once every day.
In phase II, message exchange starts with offers from the initiator. In message 1, as seen in Figure 19-8, the initiator offers some options and information to calculate the shared-key. These are public DH (pk-i), initiator nonce values which are a big random number (N-i). All of this information is transferred in encrypted format.
Figure 19-8. Phase II Message 1
 View figure. |
In message 2, the responder provides the similar information (N-r, pk-r), to the initiator in addition to them. It selects one of the options which were provided to itself.
Now each Network Utility knows the following about the others:
The DH calculation is performed to generate the phase 2 shared secret. The keying material for traffic going from the responder to the initiator is the hash of SKEYID_d, the shared secret, protocol, SPI of the initiator, and two nonces.
All the necessary keying material has now been exchanged. Message 3 proves the connection is alive.
Refer to Nways Multiprotocol Access Services Using and Configurating Features for further explanation of the following protocols.
Layer 2 Tunneling Protocol (L2TP) is the IETF standard's track protocol for tunneling Point-to-Point Protocol (PPP) traffic across an IP network. L2TP uses a UDP transport for both tunnel setup messages and to transport PPP data between endpoints. L2TP is a client-server architecture with a client called a L2TP Access Concentrator (LAC) and the server called a L2TP Network Server (LNS).
Layer 2 Forwarding (L2F) is a tunneling protocol that was developed by Cisco Systems, Inc. It provides the same solutions as L2TP. When the IETF developed L2TP, they reused some of Cisco's L2F and Microsoft's PPTP. IBM routers implement L2F to interoperate with Cisco routers. Between the IBM routers, L2TP is used because it is an IETF standard.
L2F defines two devices--a NAS and a home gateway.
Point-to-Point Tunneling Protocol (PPTP) has the same aim as L2TP: to tunnel PPP packets across an IP network. L2TP was developed by the IETF and is based heavily on PPTP and L2F (Cisco's equivalent). To establish a tunnel with a Microsoft device, IBM routers need to support PPTP.
PPTP is a client-server architecture with a client called PPTP network access concentrator (PAC) and the server called a PPTP network server (PNS). According to the architecture, the PAC is typically a workstation and the PNS, a server.
Voluntary tunneling is a client-initiated model. The client/PAC dials into the NAS, gets an IP address and establishes regular network access. Afterwards, it opens another dial-up session which establishes the PPTP tunnel. There are two scenarios in which IBM routers can be used with a voluntary tunnelling PPTP. The IBM router can either terminate the tunnel or initiate the tunnel. If it terminates the tunnel, the client initiating the tunnel must be PPTP capable and could use an NT or Windows device or any other device supporting PPTP. In the second scenario, a router could establish a tunnel back to a PPTP device, such as an NT server.
Compulsory tunneling is a router-initiated model. In this scenario, the client has no L2TP knowledge. The client dials into the LAC and the LAC initiates the L2TP tunnel back to the LNS. In this case, the LAC sends an incoming-call-request to the LNS. Since the client and the LAC have already negotiated LCP and partial authentication, the LAC passed this information to the LNS in what is called proxy-authentication. After call establishment, the LNS completes PPP authentication and network phase with the client through the newly formed tunnel.
The following four subsystems will help you debug and determine the status of your VPN configuration.
The L2 Subsystem contains the ELS Messages for all of the layer 2 tunneling protocols including L2F, L2TP, and PPTP. This subsystem shows information about tunnel and call establishment and termination. It also shows information about packets received and transmitted through the L2 tunnels. Error messages resulting from failed negotiation of the tunnel are also displayed.
The ELS messages for the PLCY Subsystem tell about the status of the policy database refresh, how many rules where loaded into the database and information about errors that may have occurred when the policy database was being built. You may look at the packet information for policy database queries, what rules and actions resulted from these queries and any errors or other information pertinent to negotiations involving the policy database.
The IPSP Subsystem contains messages for the IPSec module in the router. The IPSP subsystem shows information about packet encryption and decryption, the algorithms that are being used and error messages resulting from packets being discarded because of failures.
The IKE Subsystem shows information about the phase I and phase II negotiations which ultimately setup a secure IPSec Tunnel between two security gateways or hosts. Any errors that result from failed negotiations due to pre-shared key mismatch, security proposal mismatches or policy errors will be displayed.